@retronym Scalac doesn't null out singly used private fields after use in lazy initialization if they are defined in a trait: https://github.com/scala/scala/blob/b3e380a08e4f8781f89412c4921f380a4b4758e9/src/compiler/scala/tools/nsc/transform/Mixin.scala#L381
What is the reason for this restriction?

can be null -> can be nulled

Same typo here

Same typo here

Should a markdown code block instead

Indentation is off... While you're at it, could you also add the missing code blocks in this file?

Does this cover cases like this:?

class TestByNameLazy(byNameMsg: => String) {
  lazy val byLazyValMsg = {
    def foo = byNameMsg
    foo
  }
}

No, I am being conservative here (so is Scalac).

In this case it is Ok to null out byNameMsg once byLazyValMsg is initialised. But there are cases where a reference to byNameMsg might leak out of the lazy val initialiser. For example:

trait Foo { def bar: String }
class TestByNameLazy(byNameMsg: => String) {
  lazy val lazyFoo = {
    def foo = byNameMsg
    new Foo { def bar = foo }
  }

 lazyFoo.bar // not Ok to null out byNameMsg
}

I haven't put too much thought into figuring out when it is safe to null out byNameMsg, but I believe requiring that the lazy val and the field are defined in the same class, and when using the field the owner is the lazy val is restrictive enough.

Sounds good to me!

Maybe you could return a Map[Symbol, Seq[Symbol]] to avoid this conversion.

I will change it to collection.Map[Symbol, List[Symbol]] to avoid the conversion from mutable map to immutable map. The conversion from ListBuffer to List is pretty much free since mapValues return a view on the collection.

Actually I took a different approach. I return a mutable map so that LazyVals can clears entries that are not needed anymore

Any reason to do this so early? I think the closer the collection is to the LazyVals phase, the better. It cannot be in the same group as LazyVals or the group before since that's Erasure, but it could be in the ErasedDecls group, no?

I tried, but I think I need to run before Getters. Consider the following example:

class LazyNotNullable {
  private val a = 'A'.toInt // not nullable type
  lazy val l0 = a
}

If I run after getter, I only see a as def a: => Int. But then, how can I differentiate between this a and the following:

class LazyNullable(a: => Int) { 
  lazy val l0 = a
}

The first a is not nullable, the second is. Any suggestions?

If you run after ElimByName then all vals with type => Int will have been replaced by vals with type () => Int, so you don't need to null anything with ExprType.

Ideally we should clear() this map once we're done with it, this can be done by overriding transformUnit.

This will do the wrong thing if you have more than one unit, by the time you get to the group where LazyVals is present, this method has been called for each unit, so all maps but the last one are forgotten.

If the Module check is needed, add a comment explaining why

You can use MutableSymbolMap instead.

This comment isn't very clear, what simplifications?